1. Field of the Invention
The following invention relates generally to software build control, and more particularly to a software build control tool that automates the build control process by using the original program files as input and automatically identifies all shared library files.
2. Related Art
The software build process is the process of building executable software modules, also known as software files, from source code modules. It consists primarily of compiling one or more source code modules (i.e., header files and program files, as defined below) into object modules, and then linking and combining the object modules into one or more executable modules.
Source code modules (also known as source modules) consist of those modules that contain a programmer's original source code for an application, referred to as program files, as well as existing modules that contain source code commonly used and shared by many applications, called shared modules. Shared modules are also called header files. In the C/C++ language programming environment, program files are conventionally given a ".c" extension, while header files are conventionally given a ".h" extension.
Header files can be used to specify such information as file formats, standard routines, standard input/output functions, and constants (so that variables can be reset easily without being "hard-coded" in program files). These files are commonly referred to by different nomenclatures depicting the respective functions they perform, such as copy libraries, shared libraries, or include files These may be specific to a vendor's product, or may belong to the public domain.
Essentially, the compilation process includes all modules that contain source code and are to be used to build final executable modules. All source modules, including both original source modules and commonly used shared modules, are compiled into object modules. An object module contains machine instructions that specifically corresponds to the original source code of a source module. In the C/C++ language programming environment, object modules are conventionally given a ".o" or ".obj" extension.
Object modules must be link edited, commonly referred to as "linked," by a link editor program before they can be executed. A link editor program link edits (or "links") object modules to create an executable module. This process includes combining the individual sections of the object modules into one larger object module with four sections, specifically header, program, relocation and symbols sections. A discussion of link editing is provided in Kaare Christian, "The UNIX Operating System", second edition, (John Wiley & Sons, New York, N.Y., 1988).
In most programming languages, executable modules commonly have a filename with an ".exe" extension. Each executable file is specific to an application desired by a programmer.
There are also shared executable modules. For example, Dynamic Link Library (DLL) files are executable modules that reside in shared libraries and are used by a variety of application programs. DLL files typically have a filename with a ".dll" extension. DLL files are commonly used for vendors' communications utilities, user interfaces, and other prevalent applications.
In a typical software development environment, program files and associated header files reside in a developer's library until they are ready to be compiled. These source modules, consisting of program files and associated header modules, are then migrated to a configuration management library. It is from the configuration management library that the software build process takes place. In many of the complex software systems that are built today, hundreds of source modules are compiled into hundreds of object modules for a single application. These object modules are then linked and combined into several executable modules. T here are several tasks and considerations involved in the software build process. With so many modules of different types involved, a modification to one module may or may not require a recompilation of one or more other source modules.
One well-known UNIX utility program used in the C/C++ programming language is called "make" (hereinafter "Make"). Make assists in managing the build process. Make provides an interpretive language that can be used to write instructions for compiling and linking. Specifically, Make provides a scripting language that can be used to specify instructions to a compiler and linker.
For example, suppose a programmer wishes to perform a partial compilation by creating an object file called program.o. It should be noted that the compilation is a partial compilation because program.o does not represent the compilation of a complete program, since any complete program must include the function main( ) in the C/C++ programming language. The following instructions of dependencies for Make can be placed in a configuration data file called a Makefile:
______________________________________ program.o : program.c header.h cc -c program.c ______________________________________
When the programmer enters "make" and the name of the Makefile, the Make program reads the above instructions from the Makefile. Here, the Make program is instructed to compile the partial program file program.c and the header file header.h into the partial object module program.o. Similarly, the object module program.o and another object module called program2.o can be combined (or linked) into an executable module named run program.out by providing the following command in the Makefile:
______________________________________ run.sub.-- program.out : program.o program2.o cc -o run.sub.-- program.out program.o program2.o ______________________________________
As the above instructions illustrate, programs like Make require a person to manually specify what source modules, including header and other shared library files, are to be compiled and linked. Make does compare date/time stamps of header files, program files, and object modules in order to determine which modules must be updated. For example, if a program file or header file is found to be more recent than an object module, Make will determine this and force a recompile.
However, as shown by the above examples, with Make and programs like it, a user must identify all header files, and other shared library modules, and must also identify which source modules are to be included therewith. This requires more time and effort from the user, and is also subject to user input error. As noted, in a typical software system build, there may be hundreds of program files and header files, as well as hundreds of object modules to deal with.
A compilation error can occur when a program file references a specific header file, but the header file is not included in the configuration data file (e.g., Makefile). This can happen frequently in a large-scale software programming environment, where developers frequently break down a source module into multiple modules. Often, when a source module is broken down, the developers forget to reference a header file in each resulting module or accidentally remove a needed header file from a module. Accordingly, a developer must remember to reprogram the configuration data file, to ensure that the correct dependencies are maintained. However, reprogramming of the configuration data file may be incorrectly performed or entirely forgotten. This is especially likely given that the configuration data file is often maintained by configuration services programmers, versus the development programmers who modify the modules. In addition, the configuration data files for a large-scale software programming environment are frequently quite cumbersome and difficult to follow. Unfortunately, a missing file will likely be discovered only when an entire software build is compiled, with a resulting compilation termination error. However, by this point, much time has already been wasted in an unsuccessful attempt at compiling and linking. Often, the software build is performed overnight, with a resulting loss of a full business day for the developers and testers.
Make and other software build utilities can only use the most recent version of any source module. Often, an earlier version of a source module is needed for compiling and linking, because different development programming groups concurrently modify and test different portions of the applications software.
As an example of a compilation error, suppose a first programmer references a specific header file in a program file, which has already been compiled into an object module. Suppose further that a second programmer modifies the same header file to fix a bug, but by doing so, introduce a new bug into the first programmer's program file. This error will not appear until the first programmer's program file is compiled, linked, executed, and tested. However, by this time the first programmer will be at a loss to determine how the bug was introduced and much time and effort will be wasted in the software build.
In addition, Make and other software build utilities will not detect potential conflicts and errors between the modules. These turn up after the compilation and linking process have failed, or after an executable has been built and tested.